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ABSTRACT 


OF eC deeul. bulk email IS an efficient Look EO 
disseminating information to a wide audience. Its inherent 
efficiency, captive audience, and trust provide a dangerous 


attack vector for adversaries utilizing fraudulent email. 


Digital authentication can provide a layer of defense 
tO: OLELeial bulk email that.,. combined with ouvher detensi ve 
countermeasures, will greatly reduce its vulnerabilities. 
The Department of Defense mandates that official emails, 
which contain hyperlinks, attachments, or instructions to 
recipients, must contain a digital signature, authenticating 
the source of the email, and ensuring the integrity of its 
Contents. Tis poltey, though used: at Some. mrlivary 
inisStel Lar voms, 1s now being applied: to -orire al. bulk email 
ab WOunSrSs: -dliie ho <Adminastrarive. roadblocks, 1m jobtauninig 
role-based certificates, and implementing an authentication 


policy with legacy email systems. 


This thesis identified administrative roadblocks in 
deploying digital authentication solutions within the 
Department of Defense, explored different technology options 
Or @ drdital “authentication, sOolutnenm tor “orrircveal bulk 
email, created a proof of concept solution using a Python 
proxy server and S/MIME, and looked at the most popular mail 
user agents to see how they interpret S/MIME digital 
Signatures. Applying. dlgival. Baurienelearon . 360 Orr rertal 
bulk email will close a potentially critical vulnerability 


in the defense of DoD networks. 
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Mis INTRODUCTION 


A. OFFICIAL BULK EMAIL 


Official bulk email iS a common way for administrative 
managers to get information out to the workforce. It allows 
the sender to push a single button to get announcements, 
tasking, or other administrative direction to everyone 


within their domain or sub-domain. 


Most of us are accustomed to receiving official bulk 
email, and we typically accept its contents as valid without 
checking integrity of the message or the authenticity of the 
sender. This inherent trust of official email provides a 
dangerous attack vector to people who want to _ steal 
information, pass misinformation, Or anstall malicious 
software. This type of attack, where email is used to 
convince people to convey personal information, is called 


Phase, sia 


B. PHISHING 


Phashing abreeacks: egalnst Specific dnsreicucions; such as 
Department of Defense (DoD) commands, are becoming more 
common. The attacks are also becoming more sophisticated, 
spoofing actual official email sources with specifically 
crafted content for the target recipients. rhe Besules: ‘Oc 
these attacks range from compromised user accounts to the 
compromise of personal information and services. As 
He Filey ule o> es: and organiZalvons improve their ative k 
techniques, more and more accounts and critical information 


will be compromised [2]. 


Currently our main defense against these crafted emails 
is filtering. Firewalls and spam blockers do a good job in 
keeping out known vectors of attack such as blacklisted 
domains or executable file attachments, yet they are only 
effective against attacks that can be identified. PAGS, hs 
an AI problem, as the phishing defense must make a decision 
to allow or deny access to the network for each email it 
sees based on the email’s content. ALtackers- Understand 
this, and can eventually defeat any defense that relies on 


content-based filtering. 


C. CRYPTOGRAPHIC AUTHENTICATION AS DEFENSE 


Cryptographic authentication can severely limit the 
success rate of spoofed email, since it 1s computationally 
infeasible to defeat modern signature algorithms. By? Using 
CrypUcogreaphic seuLnenticalion: “an -cCOnqzunct1on, “with: -current 
defenses, like filtering, spoofed emails may be prevented 
from entering the network altogether. in the. future; <anti= 
spam software may automatically verify digital signatures on 
incoming email messages, removing the burden from the user. 
The Department of Defense has already deployed software that 
will verify digital signatures on the desktop, and has even 
created policy that requires a digital signature for emails 
that- Contaim Specific Types of dara (Si4 Yeu ‘thas policy “1s 
not widely enforced and many users don’t understand the need 
for digital authentication, or how to use it properly. 
Furthermore, many administrative roadblocks exist that delay 


the deployment of digital authentication technology. 


D. PURPOSE OF STUDY 


This thesis analyzes the problems associated with 
deploying a digital authentication solution to  auto- 
generated email, researched different commercial solutions, 
and. Present. a. pProor=OrF—COnNncepE Script. thal Can’ sion  auto= 
generated emails through the use of a proxy server. Le 
reviews common Mail User Agents (MUAS), shows how they 
display S/MIME signed messages, and characterizes a bug in 
how Apple Mail verifies S/MIME signatures specifically with 


Deperlment Of Detense Common Access ‘Caras. (CAC). 


We: tocused on “automated: ema versus imterective ema. 


fOr @ Number of reasons: 


1. Common Access Cards (CAC) that have been deployed 
by DoD will apply a personal digital signature to 
interactive email, but cannot be used with 
automatically generated email or with role-based 


Cert iteates, 


2. Automated emails UsSUe Lily have no reply- 
requirement, bypassing the usability problem 
associated with requiring a digital signature for 


replies. 


3. Finally, because automated emails prime users to 
accept unsigned fraudulent commands, and 
currently, no one else is attempting to apply a 


digital signature to them. 
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II. BACKGROUND AND RELATED WORK 


A. THE THREAT —- OFFICIAL BULK EMAIL AND PHISHING 


Official bulk email provides a means to disseminate 
official information to an entire organization with ease. 
These emails can be fairly common, ano: “are. Mostly 
automatically generated. Because of their frequency and 
official nature, auto-generated bulk email evoke an inherent 
trust response with their recipients. Attackers can easily 
exploit both the selected distribution of official bulk 


email and their perceived integrity. 


This use of fraudulent email is called “phishing,” a 
term coined in the early days of computer hacking. These 
fraudulent email attacks have become more technical, more 
personal, and more successful each year. Criminals have 
devised ways to increase the success rate of their attacks, 
ie Lic aenG targeting specific users with a specific 
relationship, such as customers of a bank or commerce-relate 
website. These fraudulent emails look like official 
communication from the target bank, but will usually contain 
a malicious attachment, or a link to a website that will try 
to collect personal information from the victim (see Figure 


Ly eg 


Subject: eHay Account Verification 

Date: Fri, 20 Jun 2003 07:38:39 -0700 
From: “eBay” <accountsi@ebay.com> 
Reply-To: accounts@ebay.com 

To: 


Dear eBay member, 

As part of our continuing commitment to protect your account and bo reduce the instance of fraud on 
our website, we are undertaking a period review of our mefnber acoounts. 

You are requested to visit our site by following the link given below 

httn:/ /arribbacpi3.ebay.com/aw-cepi/ebaylSAPldliUpdatelntormationConfirm&bpuserei 


Piease fill in the required information. 

This ts required for us to continue to offer you a safe and risk free environment to send and receive 
money online, and maintain the eBay Experience. 

Thank you 

Accounts Management As outlined in our User Agreement, eBay will pertodically send you 
information about site changes and enhancements. Visit our Privacy Policy and User Agreement if 
you have any questions. 


i uc, All Rights Reserved. 
Designated trademarks and brands are the property of their respective owners. 
Use of this Web site constitutes acceptance of the eBay User Agreement and Privacy Policy. 





Figure 1. Fraudulent Email Example (From 4) 


B. SOCIETAL ASPECTS OF PHISHING ATTACKS 


Phishing attacks also have indirect consequences as 
well. Societal aspects, Such aS Trust, Support, and 
reliable communication, are victims of phishing attacks in 
addition to direct monetary loss [5]. Even if a phishing 
email is unsuccessful, the ensuing trust in whatever company 
Or organization that attack mimicked is degraded. FOr 
example, a phishing attack using an address that looks like 
the Red Cross may make actual Red Cross emails requesting 
aid for the current crisis less effective. This will have a 
negative impact on legitimate organizations’ ability to 
raise funds through email campaigns [5]. A similar outcome 


occurs with banks that are imitated by phishing scam 
6 


artists. Users will be more afraid to follow links enclosed 
with legitimate bank emails. Banks will have to either 
follow safer email practices, Such aS. “using. digital 
cryptographic authentication, or fall back on alternate 
methods of communication which may be more expensive or 


wasteful (e.g., phone calls and paper mail). 


One company, PayPal, 1s attempting to initiate a 
fundamental change in how email providers handle their mail. 
PayPal’s general council states that their company is one of 
the highest targeted e-commerce companies currently in 
business by phishing attacks. Peyral sends sa: S2gnitrecant 
amount of mail to its customers, and criminals have targeted 
PayPal and those customers by sending spoofed messages that 
appear to come from PayPal but direct customer to _ fake 
websites. As a result, in 2007 PayPal asked all major email 
service providers, such as Google and Yahoo!, to block any 
email that claims to comes from the PayPal.com domain, but 


do: Mot Contain. PayPal’ s Gigital. Signature. [6]'« 


PayPal was already combating phishing attacks against 
their customers by limiting the amount of money per 
transaction and compensating users who where victims of 
phishing attacks. By attaching a digital signature to their 
official mail, they are helping both email service providers 
identify fraudulent mail, and adding another layer of 


protection for their customers. 


Cz MITIGATING PHISHING BY TRAINING 


One of the weakest links in computer security is the 
user. Nevertheless, training of users has traditionally been 


a lower PLELOLIEY among security professionals than 


7] 


preparation, avoidance, intervention, and treatment [7]. 
Because of this, the effects of user training are mixed. 
When users are confronted with traditional context-free 
phishing attacks, training has shown to significantly reduce 
the number of users who fall victim. Yet when trained users 
are presented with sophisticated context-specific attacks 
(spear-phishing), training seems to have reduced impact. 
Training also increases the likelihood that legitimate 
emails will be labeled as attacks. This, researchers state, 
1s because users, despite training, cannot recognize what 
phishing is, how to identify phishing attacks, if they 
understand what it 1s, or have an inherent trust that 
attacks shouldn’t come from recognized sources. This is a 
Eroubling conclusion Tor organi zacions: that send. bulk emaal, 
as it implies that training may make bulk email less 
effective and that even with training, these organizations 


will remain susceptible to targeted phishing attack. 


Training iS a base requirement to mitigate and prevent 
phishing attacks, but as these attacks become more context- 
sensitive, training will become less effective by itself. 
Users need both training and extra tools to either assist in 


Eran sO iO. -aSsis.. 2m ToenrI tying phishing attacks. 


Because spear-phishing uses phrases, terminology, and 
target a select group of people, automated systems have a 
harder time identifying and filtering out these attacks. 
Context specific emails will get through most generic 
filters, because they are intended for a smaller audience, 
and have specific details relating to current or recent 
DrOJeeCus. If automated systems had a high enough threshold 


to weed out these context-specific attacks, then there is a 


hogit prebability “chat, ihe: tibeers. would prevene: the -delivery 


of legitimate mail as well. 


CONESCXE=SPSCiLE RC “FrauGulene <emalls ere Ancreasing every 
year in both number of attacks and sophistication because 
they are successful. By targeting specific users, the 
criminal can bypass most automated security systems and 
increase the chances of a successful attack. The “more 
convincing their fake emails look, the more untrained users 
are likely to fall victim. Even users who were given basic 
training to identify fraudulent email still fell victim to 


the more sophisticated and authentic looking ones. 


D. THE WEST POINT EXPERIMENT 


In 2004, researcher Aaron J. Ferguson conducted a 
phishing experiment at West Point Military Academy [8]. He 
sent out a specially constructed email with an embedded 
hyperlink to a group of 512 randomly selected cadets. This 
target group consisted of an even number of freshmen, 
sophomores, juniors, and seniors. Ferguson selected West 
Point because it is a DoD facility, has a Computer Emergency 
Response Team (CERT), and was the only service academy at 
the time to be certified by the National Security Agency 
(NSA) as a Center of Academic Excellence in Information 
Assurance Education (CAEIAE). A final important factor was 
Ene Lact tinct: Sact Lresiman Chass: MnGgerwene. Loum AOUrS: OF 
information assurance training, where they discuss various 
security practices related to electronic communication, 


Pe Ma WO Olas hein. 


Ferguson’s phishing email was crafted to exploit the 
military mentality of the cadets, yet have obvious errors 
that should have caused suspicion among the recipients. The 
email was sent from a Colonel, a high-ranking officer, and 
asked the students to follow an included hyperlink, but the 
Colonel was not in West Point’s global address book. The 
Colonel. 4180. 17 sted: his office -6n the 7° floor of a weli- 
known building on campus. The cadets should also have known 
theres Was: no J" bleer of this Durlding, The experiment 
resulted in 80% of the cadets of different rank clicking on 
the hyperlink and 90% of the newly trained freshman falling 
VEC ams, Ferguson showed that even a select group of 
individuals with specialized training and within an 
organization that has a greater need of cyber security can 
still tell vWwactkim LO sSpectally° Crerted speéar—-phaushing 


attacks. 
E. DOD TARGETED PHISHING 


Phishing campaigns have expanded from ISP users and 
banks to governmental organizations like the Department of 
Defense. These more sophisticated attacks, with emails that 
look identical to official mail, are the most threatening to 


the security of Government networks and DoD members [2]. 


The United States remains the largest host of phishing 
websites in the world [9]. Thais 25° NOL an Indication. oF 
malfeasance on the part of its citizenry, but a result of 
bandwidth, target populace, and privacy laws. The US has 
both more aggregate bandwidth than any other country in the 
world and the largest number of unmanaged home computers - 
each a potential launching pad for attack. America is also 


the world financial leader, so the same users who do their 
10 


banking online are the primary targets of financially 
FOoCUSEO phashing altbacks. Favrewdiiliy, the: US: has: Struct. Laws 
protecting the personal rights of its citizens, which help 
the phishing criminals since authorities must pass through 
multiple legal obstacles to seize and analyze computers used 


ih Dien rniG eareacks. 


Phishing attacks within the DoD are not necessarily 
acCCeMpEAnNG: “CO. CGaarm <taimnanmcial. amrormation-. They may be 
targeted at government members to gain intelligence or 
account: Inrormeatuon [2]. From these compromised accounts, 
further exploitation of DoD network may be possible. Ina 
training presentation, released by JTF-GNO in late 2006, the 
DoD identified the sophistication of adversaries and their 
techniques [10]. They call these focused attacks via email 
“Sspear—phishing.” Many of these malicious emails identify 
the intended victim by name, contain attachments relevant to 
ongoing exercises, and use jargon associated with the false 
intent of the email. This leads investigators to believe 
that some attackers already have extensive knowledge of 
their targets, and know precisely what further information 


they want. 


EF. EMAIL HISTORY (SMTP, SECURITY) 


Early email systems could only transmit text messages. 
As a result, the first email standards only specified how to 
construct the message headers (From, To, Date, and Subject) 
[11]. These standards were silent on the topic of security. 
For example, RFC-821 defines the SMTP protocol, but does not 
even mention the words “security,” “authentication,” or 


Menenyoewon™ {cls . 
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Email was originally based on a protocol that does not 
inherently authenticate people, or provide for secure 
communications. The sender was identified by the From: 
address, but not authenticated. Although it was recognized 
that the From: address could easily be forged, the designers 
did not have the cryptographic tools available to allow 
authentication in a distributed environment. Besides, at 
the time email was primarily used as a way for researchers 
from different institutions to communicate - there was no 
credible threat requiring email to be protected. Teas. ere ke 
of baseline security slowed the progress of secure SMTP as a 
standard and enabled criminals to use email aS a primary 


Attack. COOL. 


As attacks and spam became more prevalent, a new RFC 
was created, RFC-2821, that now recognized these security 
concerns, and suggested “end-to-end” methods are the only 
real security solution [12]. Unfortunately the RFC goes on 
to state, “This specification does not further address the 
authentication issues associated with SMTP...” In 200d; the 
SMIP “REC was - Uopdatred -again an REC-53z217. buc..<o Further 
security extensions were proposed, Only an expanded 


discussion Of security vulnerabilities [i135]. 


G. SECURE DIGITAL MESSAGING 


People have realized the importance of secure digital 
messaging since the email user base began to grow from the 
small group of researchers to the wider public. Encryption 
schemes have been in use for conventional messaging 
throughout history, but there was always the problem of 
transporting the keys or the secret way to decrypt messages 


securely. This need drove the development of public key 
IZ 


CrYDEOOLaDNYs Algorithms such as Diffie-Hellman and RSA 
were developed specifically for the purpose of securing 
electronic mail - both by adding privacy (encryption) and by 


providing authentication of the sender. 


H. USABILITY OF SIGNED EMAIL 


Many researchers have blamed the lack of secure email 
deployment not on the competition or technical shortcomings 
of the various proposals, but on fundamental usability 
problems resulting either from poorly designed software, 
overly complex protocols, or a mismatch between the security 
requirements Or ea seal and the real-world needs OD 


organizations. 


It has been shown that despite the strength of the 
cryptography or the global acceptance of a protocol, if a 
user has trouble sending a secure message, the goal of email 
security has failed [14]. Whitten famously conducted a 
study of 12 subjects, who were given the task to create 
public/private key pairs, then send an encrypted and signed 
email with PGP 5.0; only a third were successful. Whitten’s 
experiment showed that even with training, many people have 
difficulty using security software that requires significant 
user participation. Usability 1s one of the major 
roadblocks to the adoption of digital signature software, 
and is why the technology is so slow to reach mainstream 


aAdOpr LON. 


While some researchers feel that it 1S important to 
teach normal users exactly how digital cryptographic 
algorithms work, others argue that regular users do not need 


such in-depth knowledge [15]. A basic understanding of what 


i 


digital encryption and authentication provide 1s enough 


tOo Make: The TeCnhnolLooy User us. 


As the number of users on the Internet grew, so did the 
problem of spam and phishing. This increasing threat 
eclipsed the usability problems associated with key pair 
generation and encryption for an immediate need of simple 
mail authentication with signatures. Some researchers argue 
that solving the problem of encryption must wait until the 
phishing and spam threat are mitigated. But, <dEgiutad 
authentication protocols are at a state where most users can 
receive digitally signed messages because most’ email 
programs already have cryptologic technologies built in 
eI se Nevertheless, despite the widespread deployment of 
this technology, very few emails are sent digitally signed. 
Again, usability in conjunction with the users’ perceived 
indifference toward secure messaging 1S suggested as the 


reason [16]. 


Another roadblock for the adoption of secure email 
(specifically S/MIME) is the required use of authenticated 
certificates. It 1s a burdensome task to obtain a 
certificate from a reputable certificate authority (CA), and 
the use of self-signed certificates pops up an alert on many 


mail user agents [16]. 


Despite this pop up, Garfinkel's 2005 study of the 
usability of signed email found that mail Signatures, rather 
than email encryption, could effectively help users 
withstand @ laboratory phashing -avrvack; subjects were 
protected from the attack even when using self-signed 
certificates when provided with software that implemented 


the Key Continuity Model [17]. 
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Digital signature technologies are deployed on most 
user email clients today, and do not require recipients to 
obtain their own certificate to verify signed messages. 
Though usability of these programs is still a large obstacle 
to overcome, institutions are primed and ready to implement 
Signing rules to a wide spectrum of their email, and can 
bypass much of the usability issue by incrementally 
employing the authentication protocols to certain types of 


email, like automated messages. 


ui THE IMPORTANCE OF SIGNED EMAIL 


Other work has found that even when information workers 
appreciate the importance of encrypting their mail, they 
generally do not understand the advantage to signing their 
mail. Gaw, Felten and Fernandez-Kelly conducted a series of 
interviews at ActivistCorp, a non-violent, direct action 
organization: "Although we had not explored the topic in 
depth, digital signatures seemed relatively unimportant to 
the employees we interviewed" [18]. The employees they 
interviewed at ActivistCorp stated that they had reason to 
maintain the secrecy and integrity of their messages. Most 
users knéw how to encrypt; and assurances encryption 
provides, but few understood the use or importance of 
digital signatures, and would only sign their message if it 


was encrypted [18]. 


Fritsche and Rodgers evaluated a range of cryptographic 
technologies for deployment at Lehigh University. They 
considered a range of technologies in including hardware 
encryption, secure messaging, and network security. They 
made a comprehensive list of recommendations but only 


mentioned email signatures at the end of the article. They 
Lo 


focused on solutions that require extensive work or a 
Significant change to the way the school communicates, and 
dad not discuss the DrolLocgis ts © te Simple email 


authentication [19]. 


J. PEM 


Work on the Privacy Enhanced Mail (PEM) standard began 
in. the mid. LOGOS. PEM provided end-to-end security for 
email based on public key cryptography. The PEM design was 
Eitri wea ~<a: OOS Ol. PEM provides for both message 
sealing and signing. It seals the message by encrypting 
message contents with a symmetric encryption algorithm, and 
then encrypts the session key with the recipient’s public 
key. PEM signs the message by creating a digital hash of 
the message, and encrypting that hash with the sender’s 
private key. PEM was designed when there was no common 
repository of authentic public keys, so it used a chain of 
certificate authorities to verify the authenticity of the 
individual public keys, based around the trust of a single 
root server [20]. This centralized root server became 
problematic as people discovered the costs and Illegal 


ramifications of a trusted hierarchical structure. 


K. PGP 


Pretty Good Privacy 1S a program first developed and 
released by Phil Zimmermann in 1991 [21]. PGP did not use a 
Centralized trusted -root. server for -a -chaan. of trust; 
Instead, PGP enabled users to trust whomever they wished. 
The idea was that untrustworthy certificates (and the 
organizations or people who sign them) would fall to the 


wayside as more trustworthy organizations rose to the top, 
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creating a “web of trust.” An early example of a community 
reputation model - PGP was not easily applied to current 
email programs since it required a lot of configuring and 
user knowledge. Though usability was significantly improved 
in 1997 when PGP was commercialized, PGP was never widely 
used outside a select group of cryptography advocates and 


uiMein: Seas “acer JArIS iS, 


L. S/MIME 


Development work on the Secure Multipurpose Internet 
Mail Extensions (S/MIME) began soon arter PEM was 
standardized. Users and developers were discovering the 
problems associated with the hierarchical chain of trust 
ending in a single root server, so S/MIME relaxed this 
DOL Tey. Its developers envisioned a network of trusted 
certificate authorities, any of whom could provide the trust 
fOr 2andividual cerita ficates., EVen “more -cOonvenzent;. the 
software makers implementing S/MIME could include these pre- 
determined and trusted CA public keys with their software 


‘ohiksien an aio iu umealken ale 


itt LOGO, MirGrosort Corporation announced at would be 
rniciuding S/MIME. an “Cheie maid. service products (Outlook, 
Exchange client, and Internet Mail). ees sparked 
Microsoft’s competitor, Netscape, to also include S/MIME 
SUPDOOrL; 1- ES: DrOducEs:. Barly support for S/MIME from 
these industry giants pushed the secure messaging protocol 
into the homes of millions of users (most without realizing 
they had the functionality). Today, most commercial email 
mail user agents (MUAS) support S/MIME. This wide-spread 


support is one of the greatest advantages for S/MIME. 
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S/MIME is not used by a majority of individuals though. 
Many webmail systems do not support S/MIME, although there 
is support for S/MIME signatures in Outlook Web Access, and 
some support for Gmail with a browser plugin. S/MIME also 
suffers from the same problems that trouble public key 
infrastructure. There are also some ambiguities in the RFC 
describing certificate LOrmat,; which may lead © 
incompatible S/MIME implementations. Users. MUST! ialeo- Eirse 
Oba personel Cerlitiveace: betore: They Can Crgitally sagn 
or encrypt email. This process is intimidating and can be 
confusing to people who do not fully understand the method 
of acquiring a valid personal certificate. Finally, S/MIME 
authenticated messages contain a multipart section with a 
.p/s file extension for the digital signature. Since all 
mail user agents do not implement S/MIME, individuals may 
get confused when this Signature 1s displayed as an 


attachment. 


M. DKIM 


DKIM is yet another attempt to create an end-to-end 
authentication scheme for digital mail. bes Goal as Lo 
overcome the problems with S/MIME. DKIM was started as 
Domainkeys, a system developed by Mark Delany at Yahoo! 
Yahoo! and Google deployed DomainKeys in 2004 on a trial 
basis to mutually verify mail leaving and entering their 
respective domains. At the same time, Cisco Systems was 
developing its own email authentication option, called 
Internet Identified Mail (11M). Cisco and Yahoo! began 
working on a new standard that combined both Domainkeys and 
IIM; This resulted in a formal IETF proposed internet 
standard in RFC 4871 as DomainkKeys Identified Mail (DKIM). 

ilies: 


DKIM’ signs. mail. at. the domain level. iheae. Jey: a 
message originating from a user (e.g. user@nps.edu) 1s 
Signed by the domain (nps.edu) and not with the user’s 
personal certificate. Whereas S/MIME adds an attachment to 
a message, DKIM adds new fields in the message header; these 
fields are simply ignored by mail servers that do not 
support the DKIM standard. This advantage allows DKIM to be 
deployed incrementally since it has no impact on users whose 
software does not support the standard, unlike S/MIME or 
OpenPGP, where program implementations typically highlight 


errors rather than ignoring them. 


Keys are not assured through certificates (and the 
Signing certificate authority), but by the domain owners 
ENemselvVes. This enables a much more streamlined method of 
generating a public/private key pair, but also removes a 
level OL CEuUSt that eS inherent with certificate 


authorities. 


Finally, DKIM relies on DNS. The public key for the 
domain 1s stored on the domain’s name server, enabling 
anyone to obtain its public key to verify a signature. This 
form of key distribution relies on the authenticity and 
availability of DNS, which itself isn’t secure or without 
error, but has proven itself to be reasonably reliable over 
the years. DNSSEC is also being deployed, which will 


prevent spoofing DNS replies. 


N. ONGOING DEPLOYMENT ISSUES 


Some researchers have suggested that the difficulties 


in deploying signed email on the Internet today are a result 
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of the poor match between the S/MIME and PGP protocols and 


the real-world needs of large-scale organizations. 


Goodman, Cormack and Heckerman argue that S/MIME and 
PGP. bave’ mot DEGh: adopted because of “Che. burdens thal. the 
protocols place on the end user and suggest that DKIM will 
be more successful because it relies on identity at the 
domain level [22] « They state that user-level 
authentication is confusing to some users, and require an 
extra attachment of some form in the email to work properly, 
where DKIM and SenderID sit at the domain level, relieving 
the burden on the user [22]. By using domain level 
authentication, public keys are stored on the domain’s DNS 
server, and the authentication process takes place between 
servers. The entire process 1s completely transparent to 


the user. 


Boosting this argument is the fact that major web mail 
companies like Google and Yahoo! are using this technology 
today. Yet spammers were also early adopters of domain- 
verified mail. When SenderID started out, Spammers were the 
ones who were verifying that their spam email came from 
their spam websites! Domain-level verification works well 
to prevent an important domain from being spoofed (like 
PayPal.com), but it doesn’t make any guarantees about the 


nature of the verified mail. 


There remain ambiguities and discrepancies with more 
mainstream protocols like S/MIME. RFC 3850 describes how 
end-user Certiuricates: should ‘be «created, to anclude ‘where 
email addresses should be place and how verification should 
check. The problem is the use of the word “should” rather 


than “must.” Because of the suggestive nature of the RFC, 


ZY) 


different entities create end user certificates differently, 
and mail user agents verify them differently. This thesis 
discovered an example of that problem when the Apple Mail 
user agent would invariably fail to verify DoD certificates. 
That issue is discussed in more detail later, but serves as 
an example of how the S/MIME protocol can be interpreted 
differently, leading to incompatibility among certificate 


SUL ROTrLeLesS: Ane. Verrier reatiton SOorteware. 
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IIIT. DIGITAL AUTHENTICATION AND THE DEPARTMENT OF 
DEFENSE 


The Department of Defense understands the importance of 
high integrity secure messaging. The Joint Task Force - 
Global Network Operations (JTF-GNO) is a subset of the DoD 
whose mission statement was developed to ensure, among other 
tasks, “assured Lit Ormat 1on protection and assured 
information delivery” [23]. Policies derived emulating from 
JTF-GNO drive the actions and policy of the rest of the DoD 


warfighting branches. 


A. POLICY 


Because of the increased threat to DoD networks by 
spear phishing, message authenticity and security has become 
a major component of JTF-GNO’s concept of operations. i bmial 
september of 2006, the Navy issued a restatement of digital 
Signature policy based on JTF-GNO Communication Tasking 
Urders (ClOs) sand: -prvor DOD PRI -polacy I24). NAVADMIN 
248/08, “Implementation of Navy Electronic Mail (Email) 
DaG aes SLOneature. Policy,” COnMtains  ‘polney EOe WaLel 
unclassified email sent from a Department of Defense (DOD) - 
owned, operated, or controlled system or account...[for] all 
emails requiring data integrity, message authenticity, 
and/or nonrepudiation..” [24]: The Policy states the 


requirement to apply a digital signature to any email that: 
e Directs, tasks, or passes direction or tasking. 


® ReEQUESES Or FeSDOnGS: "LO: PreQquests Lor Tesources: 


A 


e Promulgates organization, position, or information 
external to the organization COATS LO Ty 
department, or command). 


e Discusses any operational matter. 


e Discusses COontrace INtOrmatl Lon, financial, or 
funding matter. 


e Discusses personnel management matters. 


e The need exists EO ensure that the email 
Originator is the actual author. 


e The need exists to ensure that the email has not 
been tampered with in transit. 


e Is sent from a DoD-owned system or account which 
contain an embedded hyperlink (e.g., active link 
to a web page, web portal, etc.)... 


e Is sent from a DoD-owned system or account that 
contains an attachment (any type of attached 
file). 

The policy also states, “Pure text references (non- 
active internet. links) to web addresses, wunitorm resource 
locators (URL), or email addresses do not require a digital 


Signature” [24]. 


Ths: pOlwrvcy <pplues: ‘both, “Go: Eman, trom andivtouels: end 
from email from group accounts, such as automated bulk 


email. 


To help accomplish this requirement, the Navy has 
issued both Common Access Cards (CAC) and CAC readers to all 


Conmeanos (io) L241. 251. 
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B. DOD CAC CERTIFICATES 


While working on this’ thesis, we discovered an 
inconsistency between the way the Department of Defense 
creates personal certificates for Common Access Cards and 
the way that certificates from other sources (such as Thawte 
and Verisign) are formatted. This inconsistency, combined 
with an implementation error present in some mail user 
agents, prevents CAC-signed mail from being properly 


validated in some cases. 


Mail User Agents may verify S/MIME Signatures 


INCOrrect ly. FOr CGxample, Microsoft products (Qurlook, 
Entourage, etc.) will verify an email address in the “RFC 
822 Name” field. This is only place in DoD certificates 


where email addresses reside. 


Other MUAS, including Apple Mail version 3.5 (930.3), 
will check for an email address appended to the end of the 
Common Name field. This was a non-standard usage adopted by 


venders in the early days of S/MIME. 


Verisign and Thawte put the email address in both the 
RFC 822 Name field and append it to the CN field, and 


Subject Alt Name of x.509 v3 certificates field as follows: 


Certificate: 
Data: 
Version: 3 (0x2) 
Serial Number: /d:7e:6d:8e:8c:07:97:£5:£9:58:d0:46:54:c2:ff£:94 
Signature Algorithm: shalWithRSAEncryption 
Issuer: C=ZA, O=Thawte Consulting (Pty) Ltd., 
CN=Thawte Personal Freemail Issuing CA 
Validity 
Not Before: Dec 8 07:52:47 2007 GMT 
Not After : Dec 7 07:52:47 2008 GMT 
Subject: CN=Thawte Freemail Member/emailAddress=slgarfin@nps.edu 
X509v3 extensions: 
X509v3 Subject Alternative Name: email:slgarfin@nps.edu 
KS09VS. Basie “CONSEralnie): Crit real 
CA: FALSE 


Ao 


But the Department of Defense will only put email 
addresses in the RFC 822 Name field (Subject Alternative 


Name) as follows: 


E) DoD Root CA? 
Le DOD EMAIL CA-15 


Y Ee SLACK.ANDREW.ALBERT.1133739226 





: Chevitfais SLACK.ANDREW.ALBERT.1133739226 
ile ahaa Issued by: DOD EMAIL CA-15 
“ hae Expires: Sunday, May 31, 2009 4:59:59 PM PT 
© This certificate is valid 





w Details 


Subject Name 

Country Us 
: Organization U.S. Government 
™ Organizational Unit Dot 





‘Qyganizational Unit PKI 
Orgam@ ational Unit USN 


Common Name SLACK.ANDREW.ALBERT.1133739226 


Issuer Name 
Country Us 
Organization U.S. Government 
Organizational Unit DoD 
Organizational Unit FEI 
Common Name DOD EMAIL CA-15 


lated 


Figure 2. DoD CAC Certificate 


[=] DoD Root CA? 
- DOD EMAIL CA-15 


LY EF SLACK.ANDREW.ALBERT.1133739226 





Extension Subject Alternative Name (25 29 17) 
x Critical NO 
"RFC 822 Name aaslack@inps.edu 
NT Principal Name 11337392276@mil 
Figure 3. DOD Email Certificate (RFC 822 Name) 
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This difference will produce the following results in 


Apple Mail: 


F 


3 Unable to verify message signature (?) ( Show Details) | 









Aovermber 20. 2008 TT 231 ARP 
Slack Andrew A <aaslackGnps edu 
Simson Garfinkel (CIV) <slgarin @nps.edu> 

i 2 Acme. 6.3K | Saves hue: Linn 


aseacahon: UNCLASSIFIED 





Your User Certificates have been generated. 





Thé attached PDF's contain he instructions for retrieaving he user cars. 

The 

* WAL in these instrections is 2 globally load balanced address which may not 
work. instead you will need to go to a local. Try 

hii 8ea-1 7 ckoki niLdisa milcarootler. hin 


nsiead of 


hitnsid-sw okitest oandm. isa milicarootlert him 





Please do not hesiiaie 10 Contact me wilh any questions of concerns 


fe eyo a] , a 


Figure 4. Apple Mail Digital Signature Error 


Because the DoD does not put the sender’s email address 
in the certificate “Common Name” field, and Apple Mail 
didn’t check for an email address in the “RFC 822 Name” 
field, the MUA alerted the email recipient that the 


Signature cannot be verified. 


The Apple Mail MUA was verifying S/MIME signatures 
differently than Microsoft products. A bug report was 
Submitted to Apple. Apple appears to have fixed this bug in 
OS X 10.5.6 as a result of our bug report. It was an 


important security concern for the DoD since valid 


2/7 


Signatures will be flagged in Apple Mail, undermining the 


purpose of the digital authentication. 


This example is an illustration of how different 
vendors implement S/MIME. Were S/MIME in wide use today, 
these problems would have been long ago identified and 
corrected. It also shows the Department of Defense can work 


with vendors to have such problems resolved. 


Inconsistencies with S/MIME implementation, especially 
within the Department of Defense, can cause a verification 
failure. Because all DoD certificates fail to verify in 
Apple Mail, users of this MUA may begin to ignore all the 
warnings associated with digital authentication, diminishing 


the benetrits that. S/MIME. can: of rer. 
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IV. NPS EMAIL ARCHITECTURE 


The Naval Postgraduate School provides robust email 
capability to all NPS students, faculty, and associates 
(CONELTACT OLS; -CUC.). The system utilizes Barracuda SPAM 
filters, and Microsoft Exchange 2003 email servers. Ty Biss 
chapter evaluates the NPS email system as a case study for 
how. “ah “organization <could -deploy -digital Signatures for 


automatically generated bulk email. 


Automated mail at NPS gets generated in a number of 
ways. One way is from Bulkmail@nps.edu. This mail is 
created by an authorized user and sent from a program 
running on an internal server. Other automated mail is 
generated by SQL@nps.edu, the role-based user for the NPS 
academic management system. This system regularly sends out 
reminders to instructors about required actions within the 
course management system, and can send email to students 
based on the classes for which they are registered. Mail 
that 1S generated internally 1S sent directly to the 
exchange cluster, without being processed by the barracuda 


filters. 


NPS hosts email for students, faculty, and associates. 


DoD regulations prohibit forwarding email outside of NPS. 


A SIGNING OPTIONS 


There are several places where NPS could sign 


automatically generated messages: 


a. Message generation 
b. After generation 


c. Upon receipt 
29 


is Message Generation 


The first solution, implement digital authentication at 
message generation, is the most straightforward solution, 
but requires modifying legacy code. Also, our target 
automated systems also are two separate entities, SO 
different scripts have to be modified to accomplish the same 


task. 


This is the most sensible way to sign official bulk 
email. The required certificates would be located at the 
message generation servers, matching the security of the 
Scripts to that of the certi1ticates. It is also the most 
secure way, Since the messages are sent from the server 
already .sagqned .and do Mot. Yequire..a proxy Server -LO apply 
any further processing. Signing official bulk email at 


message generation is the proposed method for NPS. 


2. After Generation 


The second alternative, implementing a proxy server 
after message generation, seems to be the easiest logically, 
but is far less secure than Signing at message generation. 
This approach allows the emails to be generated at different 
systems, and signed at a single point. Applying a digital 
Signature to a completed message is a relatively simple 
task, as long as the signer possesses valid certificates and 
corresponding private keys fOr. “CMe specific senders 
(BulkMail@nps.edu and SQLMgr@nps.edu). Each automated email 
generator we are targeting could be set to send unsigned 
messages to the signer; the signer would then forward it to 
the mail delivery agent. Essentially we would have a 


Signing proxy server here that would effectively intercept 
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all mail from these two sources, apply a digital signature, 


and then send it to the users. 


As previously stated, this ease of this method comes 
with serious vulnerabilities. The use of a proxy server 
adds another vector of attack for adversaries, and increases 
the complexity of both the system and the necessary 
security. To avoid this, the proxy must be configured to 
accept email only from the designated sources. The sole 
advantage of this append is that it does not affect 


production scripts other than changing the mail relay. 


We created such a proxy server proof-of-concept in this 
FashiOMi; It 1s not the most secure way to accomplish the 
goal of authenticated official bulk email, and should only 
be considered iar Soir Lag at message generation 1s 


impossible. 


Ss: Upon Receipt 


The final alternative of signing mail when received is 
highly illogical as it describes a process of getting the 
message first then applying an authentication signature. 
This defeats the purpose since the user has already received 


the message! 


eal 
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V. SIGNING MESSAGES WITH S/MIME 


There are three standards-based approaches for signing 
mail today: S/MIME, PGP, and DomainkKeys/DKIM. This chapter 


reviews S/MIME and discusses our results in signing S/MIME 


messages. 
Ay S/MIME 
Multipurpose Internet Mail Extensions (MIME) 41s a 


COMMUNLCaAEDONS “Standard ‘chat. provides. a@ coOmmom protocol for 
all email messages. This allows different operating systems 
with different mail programs to interpret email correctly. 
Secure MIME (S/MIME) is an extension to MIME that allows for 


digital signing and encryption. 


S/MIME works through asymmetrical key algorithms (like 
RSA). A user must first obtain a certificate with a 
public/private key pair. It should also be signed from a 
trusted certificate authority, though users may create 
personal certificates and sign them with self-generated 
keys. S/MIME therefore authenticates the individual who 
Signs the message, given trust in the individual or 


authority that signed the individual’s certificate. 


To create a digital signature in S/MIME, the user’s 
email message is first encoded in MIME format. A digital 
hash is then created from the email. This hash is then 
encrypted with the sender’s private key. Next, the mail 
program creates a new multipart MIME message, with the old 
message as the first part and the S/MIME signature 
consisting of the signed hash and the sender’s certificate 


as: Che “Second ‘part. This is the message that gets sent 
oO 


across Ene Interne. On the recipient’s side, the public 
key is extracted from the sender’s certificate and used to 
decrypt the signature. The recipient then hashes the 
Original message, and compares the result to the decrypted 
hash. If the two match, the receiver is assured that the 
message was not modified in transit and that the owner of 


the certificate sent it. 


There are two usability problems with S/MIME. First, 
since S/MIME expands the original message by including the 
digital signature and attaching the sender’s certificate, it 
requires a MUA with S/MIME support to verify the message 
correctly. Programs that do not implement S/MIME typically 
show the original message with an attachment; this file with 
.p/s attachment may confuse users who do not understand what 
it is. Second, many S/MIME agents will warn the user if a 
Signature does not match, cannot be verified, or any other 


number of errors possibly associated with S/MIME. 


One of the largest advantages to S/MIME is its industry 
ACCeP UENCE. Most of the mainstream MUA’a implement the 
S/MIME standard, and can process these signed or encrypted 


MEeSSages. 


B. IMPLEMENTING S/MIME 


For this thesis, we decided to use a proxy SMTP server 
that would receive automatically generated emails from two 
different sources, apply a digital signature based on the 
source, then forward that message to a production server for 
delivery. We looked at three solutions for this proxy 
server: a product meant for extremely large enterprises, one 


that was designed for smaller institutions, and finally a 


34 


proxy server written in the Python language using a 


well-known library called Twisted. 


1. ColdSpark Solutions 


We reviewed the ColdSpark mail processing system. This 
company typically caters to Fortune 500 businesses, which 
need the ability to process millions of emails at one time; 


SOLUETONS: Stert- ac 3250-000, 


2: PGP Universal 


We tested the PGP Universal Server by OpenPGP. This 
product was more in line with the requirements and budget of 
Our “OL Canizat POs We obtained from PGP an evaluation 
license for the PGP Universal server. PGP Universal Gateway 
Email S6rver i2S:a product “that perrorms. a tot Of. DPunctions,; 
it acts as a router, is a stand-alone email server (complete 
with functionality and administrative rules regarding user 
mailboxes), and has a wide variety of options to implement 
rules based on different aspects of received or generated 
email. Tiss; soroGduel: as: ~~: Jie race: or 3S, 120. We 
configured the server running on a laptop with its own 
static IP and DNS entry on the NPS network, behind the 
firewall. We were able, with some difficulty, to import 
test certificates Or Derh “BulkMail@nps.edu” and 
“SQLMgr@nps.edu.” These were both self-generated and signed 


Certificates. 
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3. Python Scripted Server 


Our third way of implementing a signing-proxy was to 
GSevelopm: «Our ©Owh, We used a well-used set of libraries 
written in Python called Twisted to flesh out our SMTP 
server. Using the programming language Python allows us a 
very lightweight and easy to program application that is 
operating system independent. The Twisted framework is a 
networking engine, supporting numerous protocols, including 


SMTP [26]. The sample python script appears in Appendix A. 


4. Obtaining Test Certificates 


We obtained test certificates by going through a 
process instituted by the Defense Information Systems Agency 
(DESAY This process mimicked the actual process of 
obtaining email certificates within the Department of 
Defense, but all information we entered was fake test data 
(oy Sisk Truce torn). The test certificates enabled us to 
digitally sign test messages through the use of OpenSSL via 


a. DYE AOU SeCriLpe s 


Once the SMTP proxy server waS running, it awaits an 
incoming message. When it receives an email, it will copy 


the headers so it can forward the signed message to the 


appropriate production SMTP server. The signing proxy then 
calls a function to sign the message. This function uses 
the OpenSSL command to create the signature. ine -Oene. la 


commanc then. returns the message + Signature to The signing 
proxy. From there, the proxy forwards the signed message to 


a production SMTP server. 
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This proof of concept was a fairly trivial example, but 
it has serious security flaws that must be addressed before 
akg @ aS considered as a viable SOLULLOn: AS LErse 
vulnerability 1s the connection between the generating 
script and the proxy server. We “Creaced ‘the ese message 
via command line, but in a production system, we would use 
existing scripts and automation. The message is unsigned 
from this source to the proxy server, allowing an attacker 
the exact same attack vector that we are trying to solve. 
The adversary can spoof the bulk email “From” address, and 
send whatever phishing message to the proxy server. Without 
any verification, the server will sign the fraudulent email 
and forward it to the intended recipients. The recipients 
will see a valid digital signature and fall victim to the 


attack... 


Another vulnerability of the proxy server is the 
storage of the certificates. The server needs to use the 
private keys for each address it is authorized to sign. 
Therefore the security of these keys is the same level as 
the security of the server itself. An adversary could 
compromise the server, obtain the certificates, and then 
apply a digital signature to any fraudulent email he/she 


wishes, undermining the value of digital authentication. 


A third vulnerability with our test proxy is the 
openness that we allowed. The test proxy will accept any 
message with any From and To address. If this were to go 
into production, then an adversary has no roadblocks to 
spoofing any message they want. Clearly, additional access 


controls are required before this system is deployed. 


oy 


THIS PAGE INTENTIONALLY LEFT BLANK 
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VI. MAIL USER AGENTS AND S/MIME 


This chapter consists of screenshots of different Mail 
User Agents (MUA) and what they show when there is a valid 
digital signature present in a message. There will be 


screenshots that show S/MIME and DomainKey/DKIM signatures. 


Pi S/MIME SIGNED BY COMMON ACCESS CARD VS THAWTE FREE 
EMATL 


This section shows what some different MUAS display 
when they look at a message digitally signed with S/MIME. 
It highlights a difference in how the DoD uses the fields 
within the personal certificate compared to an online 


Signing authority (Thawte), and how this becomes an issue. 


1. Microsoft Outlook 









S/MUMIE [INawite) signed Emall wy 
#2) Andrew Slack 8:41 AM 

S/MIME (CAC) signed email a) 
wes Si datsalinse ait ee See aaear 
cee IME (DOD) Signed emma ee Oe 

Mu ster sfirmailize: 15 KB : 


Figure 5. Microsoft Outlook Preview Screen 





ference SEY La <j Send/Receive > > | (Cy Search address books = 








S/MIME (DOD) Signed email 
~| * |) Andrew Slack [aaslack@nps.edu] 


























al = t Thu 1/15/2009 8:18 AM 
Slack, Andrew (LT) 
aud E aaslack@nps.edu B 
This is an S/MIME signed email, using my private key on my CAC. - 
Figure 6. Microsoft Outlook Digital Signature Indicator 


Se, 


Microsoft Outlook contains an icon for a signed message 
from the preview screen, and a similar icon when the actual 
message is viewed. These indicate a valid Signature, as 


shown in Figures 5 and 6. 


Digital Signature: Valid 


Subject: SIMIME (DOD) Signed email 
From: 4ndrew Slack 
Signed By: aaslack@nps.edu 


Q The digital signature on this message is Valid and Trusted, 


For more information about the certificate used bo digitally sign 


the message, click Dekails. 


[| Warn me about errors in digitally signed e-mail before message opens. 


Close 





Figure 7. Microsoft Outlook Digital Signature Details 


By clicking on the icon, it will bring up a more 
detailed window, indicating that the signature is both valid 


and trusted. 


Digital Signature: Valid 
Digital Signature: Valid 4 iptal Sien 
r 


Message Security Properties 
—— Onn... 2t8.. Men wn oti 


| Signature wad Subject: S/MIME (DOD) Signed email 
4 | General | Details 


Messages may contain encryption and digital signature layers, Each digital 
signature layer may contain multiple signatures. 


S Security Layers 
Signature Information Select a layer below to view its description, 


Subject: S/MIME (DOD) Signed email 
Message format: S/MIME Digital Signature Layer 
& Signer: aaslack@nps.edu 








Signed by: aaslack@nps.edu 
Signature status: OK 

Signing time: 8:17:59 4M 1/15/2009 
Digest algorithm: SHA1 


Signature algorithm: R54 (1024-bits) 





Description: 
Certificate Information OK: Signed message. 


Issued by: DOD EMAIL C4-15 

















Click any of the Following buttons to view more information about or make 
changes to the selected layer: 


Certificate status: OK 
Trust ercirh 


View Certificate. . [Warn me about errors in digitally signed e-mail. 














Figure 8. Microsoft Outlook S/MIME Details 
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Outlook can display more details about the Signature, 


including who the signer is, and the identity of the 


certificate authority. 


If we replace the DoD certificate with one that hasn’/t 


been checked against a revocation list, we highlight some 


security concerns within Outlook: 


Messag 


e Add-Ins Adobe PDF 


QQ Lal a P| er Y Sor |e 


Dy Related ~ 

















| Reply Reply Forward | Delete Moveto Create Other Block \ Not Junk Categorize Follow Mark as Send to 
to All Folder~ Rule Actions || Sender — , Up> Unread || } Select OneNote 
| Respond Actions Junk E-mail ta Options Fr Find OneNote 
From: Andrew Slack [andrewslack02@qmail.com] Sent; Thu 1/15/2009 9:15 AM 
To: Slack, Andrew (LT); Andrew Slack; Andrew Slack 
cc 
Subject: S/MIME (Thawte) Signed Email 
Signed By: andrewslackO2@gmail.com g 
=| 
~ 
This is an email signed with a free Thawte email certificate. al 
Digital Signature: Valid 
Subject; S/MIME (Thawte) Signed Email 
From: Andrew Slack 
Signed By: andrewslackO2@gmail.com 
The digital signature on this message is Valid and Trusted. 
For more information about the certificate used to digitally sign 
the message, click Details. 
[_] Warn me about errors in digitally signed e-mail before message opens. 
Figure 9. Microsoft Outlook Certificate Warning 
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Figure 10. 


Figure 11. 


Digital Signature: Valid 


Message Security Properties 


R Subject: S/MIME (Thawte) Signed Email 


Messages may contain encryption and digital signature layers, Each digital 
signature layer may contain multiple signatures. 


Security Layers 
Select a layer below to view its description, 





wv Subject: S/MIME (Thawte) Signed Email 
Digital Signature Layer 


Signer: andrewslackO2@qmail.com 





— 


Description: 





Warning: 
The Certificate Revocation List needed to verify the signing certificate 





is either unavailable or it has expired, 
Sianed hy sndramelsceLOIMarmsil cam vicina DCAICHAL st 10:24 AM 








Click any of the Following buttons to view more information about or make 
changes to the selected layer: 


Edit Trust... Yiew Details... Trust Certificate Authority... 
[| Warn me about errors in digitally signed e-mail, 





Microsoft Outlook Warning Properties 





Signature Information 


Message format: S/MIME 

Signed by: andrewslackO2@gmail.com 
Signature status: Warning: There were problems 
Signing time: 9:15:34 4M 1/15/2009 
Digest algorithm: SHA1 


Signature algorithm: RSA (2048-bits) 


Certificate Information 


Issued by: Thawte Personal Freemail Issuing C4 





Certificate status: _ Warning: The Certificate Revocation List —— 








Microsoft Outlook Warning Details 





View Certificate... 


Using a certificate from a free Internet certificate 


auLhor il tyy 


such as 


Thawte, Microsoft Outlook accepts 
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the 


Signature, and indicates that it is valid and trusted. Yet 
when details are shown, there is a yellow warning sign 
because Outlook cannot check the Certificate Revocation List 
for this certificate. Exploring the warning brings further 
details, but they are obfuscated within a poor layout of the 


window (Figure 11). 


Ais Apple Mail 


This section will show what an accepted signature looks 
like in Apple Mail. In this case, I have manually accepted 
the certificate to show a valid signature. Without the 
trusting the DoD-issued certificate, Apple Mail will raise a 


flag, which is shown later in the chapter. 









% Mail ormat Window Help BD 3 FH 089 Thussiam _Q 
1000 Inbox (196 messages) Of 





| @| ® From | Subject 


Figure 12. Apple Mail Signed Mail Preview 
N 
‘XN 2) (que orgnce cinan nuuay 


ROO S/MIME (DOD) Signed email — inbox = 








Hyes¥indrew Slack <aaslack@nps.edu> 
Subject: S/MIME (DOD) Signed email 
Date: January 15, 2009 8:17:59 AM PST 
k@ To: Andrew Slack <aaslack@nps.edu> 
Security: % Signed (SLACK.ANDREW.ALBERT.1 133739226) 


DRE This is an S/MIME signed email, using my private key on my CAC. 


Figure 13. Apple Mail Signed Mail Indicator 


43 


Apple Mail is the MUA included with OS X. It does not 
show any indication of a signed message in the email preview 
list (Figure 12), but does show a security line within the 


actual message (Figure 13). 


a. Microsoft Outlook Web Access 


Microsoft Outlook Web Access 1s an HTTP based mail 
client. It shows a signature icon for mail that contains a 
digital: Signature. Inside the message though, it 
notifiesthe user that the message signature is not valid 
(Figure 15). Also, it doesn’t show an attachment icon, but 


you can see the “<<smime.p7s>>” signature attachment below 


the message. 


istory Bookmarks Tools Window Help 
Microsoft Outlook Web Access 


Q § |S 98% Thu 8:54AM 






82 (\G\r screenshot osx Q 





Mi covect: Ofte ew p. C 
Outlook Web Access 3 New ( Wi La 
F Slack, Andre (LT) : Inbox 4 Page: FUG ors Bb 
M:oro re Subject Received T Size 
= #8 — o Andi Slack S/MIME (CAC) signed email Thu 1/15/2009 8:41 AM 9KB 
2 #8 @ Andrew Slack S/MIME (DOD) Signed email Thu 1/15/2009 8:17 AM 9KB 





Figure 14. Microsoft Outlook Web Access Preview Screen 








$ DS Ce) 98% Thu 8:54AM 


= 


M Firefox File Edi iew History Bookmarks Tools Window Help 
e0°0 Microsoft Outlook Web Access 


(4 CS) OD Ct) GOL hites:/7webmanpsedurexchange) ay ) BS RRC reenshotosx 
MM na Inbo 1 and — - a. as a z t Outlook Web . 









x al _ “ 














@ This pe has a digital signature, but it was not validated. Attachments will not be included on a reply or forward. 
From: Andrew Slack [aaslack@nps.edu nt: Thu 1/15/2009 8:41 AM 
To: 
LILLE LETTE LLL LEE LEE LE LEELA LLL EAA LESLIE ELL ESE LESLIE LLL LEE ELE LEED 
Ce: 
Subject: 


Attachments: 





This is an S/MIME signed email, using my private key on my CAC. 


<<smime.p7s>> 


Figure 15. Microsoft Outlook Web Access Signature 
Warning 
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4. Entourage 


Entourage is the mail transfer agent for Mac OS X 
included in the Microsoft Office suite. Here, it clearly 
shows an icon indicating a signed message in both the email 
list and preview panel. (Note that Entourage uses the wrong 


icon for a digital signature). 


<j] As |est| ele) SA Ke) ce) (Se & 


Inbox Calendar To Do List Sent Directly to Me 


yO nps inbox . ) Starts with $) [Fier «x 











a | 


«2 Inbox ge By: Received 
\& Drafts 

(3 Sent Items 

{E) Deleted Items (10) 





v Today 
WG. Andrew Slack <aaslack@nps.edu> 





@ Andrew Slack ike ®: Andrew Slack, Andrew Slack, andrewslack02@gmail.com 


paket my msc idles exept Gi This message has been digitally signed by the sender. View Details 
iPS endar 


(©) Andrew Slack 8:17 AM This is an S/MIME signed email, using my private key on my CAC. 
ig = ; S/MIME (DOD) Signed email 8 x . 4 : 
|G Apple Mail To Do . 
Figure 16. Microsoft Entourage Preview Panel 
ctly to Me 


Winmgsday, January 15, 2009 8:41 AM 
ad Mm Slack, Andrew Slack, andrewslackO2@gmail.com 


| This is an S/MIME sim d email, using my private key on my CAC. 





Pagure. L7. Microsoft Entourage Digital Signature 
Verification 
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By clicking on “view details,” Entourage shows a list 
of assurances from the digital signature. It is interesting 
that is has a green check next to the line that states that 
“Revocation information for this certificate has not been 


determined” (Figure 18). 


|Neweact on tan rrr 
oe 4 4 


Summary 


This message has been digitally signed by the sender. 


Message has not been tampered with. 
# You do trust the digital ID. 
he digital ID has not expired. 
maxe digital ID's e-mail address does match sender's. 
# Revocation information for this certificate has not 
been determined. 


Sender 


Click View Sender's Certificate to view the certificate that is 
recommended for encrypting messages to the sender. 


View Sender's Certificate 


Click Add to Contacts to add the sender's encryption 
certificate to your Contacts. 


Add to Contacts 





Figure 18. Microsoft Entourage Security Details 


Dix Thunderbird 


Thunderbird 1s Mozilla’s open source Mail User Agent. 
It does not inherently trust the DoD certificate authority, 
So we can see the difference between a trusted and untrusted 


Signature. 
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ee eee abe ae eee sf nies = 
S/MIME (Thawte) Signed Email Andrew Slack 9:15 AM 4 
’ 








a Subject: S/MIME (Thawte) Signed Email 
From: Andrew Slack <andrewslackO2@gmail.com> v 4 
Date: 9:15AM 
To: Andrew (LT) Slack <aaslack@nps.edu> v, Andrew Slack <andrewslackO2@yahoo.com> v, Andrew Slack <andrewslackO2@gmail.com> ¥ 


This is an email signed with a free Thawte email certificate. 


Figure 19. Mozilla Thunderbird Trusted Signature 


Tools Window Help 





, Message Is Signed 
This message includes a valid digital signature. The message has not been 
altered since it was sent. 
Signed by: Thawte Freemail Member 
¥ Email address: andrewslackO2@gmail.com 
Certificate issued by: Thawte Personal Freemail Issuing CA 


’ View Signature Certificate 
at 


— Message Not Encrypted 
‘ This message was not encrypted before it was sent. Information sent over the 
) Internet without encryption can be seen by other people while in transit. 


Gm) 


ck _plack 
i free Thawte email certificate. 








Figure 20. Mozilla Thunderbird Signature Details 


A valid signature will show an icon in the message 
itself (Figure 19). Clicking on the icon will bring up a 


summary of the signature (Figure 20). 


Muster Confirmation Email for: Thursday, January 15, 2009 sso@nps.edu 7:38 AM 
S/MIME (CAC) signed email * Andrew Slack * 8:41AM 4 








a Subject: S/MIME (CAC) signed email 
From: Andrew Slack <aaslack@nps.edu> ¥ v4 
Date: 8:41AM oe 
To: Andrew Slack <aaslack@nps.edu> v, Andrew Slack <andrewslackO2@yahoo.com> v¥, andrewslackO2@gmail.com ¥ 


This is an S/MIME signed email, using my private key on my CAC. 


Figure 21. Thunderbird Unverified Signature 


An invalid signature (or one that Thunderbird hasn’t 
validated) is shown with a broken symbol (Figure 21). 
Clicking on the details shows a window that identifies the 


problem (Figure 22). 


4°] 


5} Digital Signature Is Not Valid f Satdect at Serdier 
This message includes a digital signature, but the signature is invalid. 
The certificate used to sign the message was issued by a certificate authority 
that you do not trust for issuing this kind of certificate. 
Signed by: SLACK.ANDREW.ALBERT.1133739226 
¥ Email address: aaslack@nps.edu 
Certificate issued by: DOD EMAIL CA-15 12:16 AM 
* 7:38 AM 


View Signature Certificate - &:41AM 


\& 


1/14/09 9:12 PM 
* 12:16AM 








‘ie Message Not Encrypted 
This message was not encrypted before it was sent. Information sent over the 
38! Internet without encryption can be seen by other people while in transit. 34 
a2 GHOKY  2@gmail.com v 
d 4, 
Figure 22. Thunderbird Unverified Signature Details 


6. Google Mail (Gmail) 


Most web-based browsers do not SUPPOLEe S/MIME. 
Google’s Gmail 1S no exception. Here we can see the signed 
message, but it has no icon or any indication that the 
message has a valid signature. It does (as all MUA’sS that 


do not support S/MIME) show the .p7s attachment. 


) (-e> (98%) nu8:S6AM Q 


FO” trie 


Gmail - Inbox (1) - andrewslackO2@gmail.com (ep) 





| http://mail.google.com/mail/?hi=en&tab=wm#inbox 5 y 2 ‘Gln screenshot osx Q 


| Mac OS X Screenshot Se x _ | Microsoft Outlook Web x 
andrewslack02@gmail.com | 4 | Settings | Older version | Help | Sign out 





) Gmail 1) - andr... © |) 500 x 


Gmail Calendar Documents Photos Reader Web more yv 


i] ae) Sear Web) sunt 
™M a | Create a filter 
by soogle BETA 

















Compose Mail Light Box(As Seen On CNN) - www.LightTherapy.com - Doctor Recommended Light Products Warranty & Satisfaction Guarantee! Sponsored Link < > 

Inbox (1) (Archive ) Refresh 4 - 50 of 58 Older» 

Starred ¥¥ Select: All, None, Read, Unread, Starred, Unstarred 

Chats P © — Andrew Slack S/MIME (CAC) signed email - This is an S/MIME signed email, using my private key on my CAC a 8:41 am 
Figure 23. Google Mail Preview 


« Back to Inbox [( Archive ) ( Reportspam ) [ Delete ) |More Actions ¥ 


S/MIME (CAC) signed email =» | 
Andrew Slack to Andrew, me show details 8:41 AM (19 minutes ago) @ ¢ Reply| ¥ 
This is an S/MIME signed email, using my private key on my CAC. 





D smime.p7s 
5K Download 


© Reply “ Reply to all —> Forward 











VOMOlk<t 2OF7~E 2fecHain 


Figure 24. Google Mail Signed Message 
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The Firefox browser (by Mozilla) does have an available 
“S/MIME” plug-in for Gmail, but it only allows a user to 
decrypt, encrypt, or sign a message; not verify a signature 
(Figure 25). 


S/MIME (CAC) signed email = = |* l 


Andrew Slack to Andrew, me show details 8:41 AM (19 minutes ago) @ > Reply| ¥ 
This is an S/MIME signed email, using my private key on my CAC. 


smime.p7s 
5K Download 








© Reply “ Reply to all —> Forward 








Figure: Zo; Firefox Plugin S/MIME Verification Error 


WV: Yahoo! Mail 


Yahoo! Mail is another web-based mail user agent. It 
also does not support S/MIME, and shows the signature as an 


attachment. There is no S/MIME plug-in for Yahoo! Mail. 


























x, Check mm Sew © #} Home I Inbox 660 messages x rv) Message Sent | rv) Message Sent x | Mobile | Options v | Help 
Qs Search Mail.. | Go] [i Delete 4A Reply ~ SAPP Forward [Spam [iL Move+ 4 Print More Actions ~ View ~ | 

go , \C | @ | From _ Subject | Date y | Sze 9\t 

© Only $4.99/mo. O Andrew Slack S/MIME (CAC) signed email Thu, 1/15/09 8:41 AM SKB ft) f 

Figure 26. Yahoo! Mail Preview 
|a- Search Mail.. | Go J WW Delete pay Reply Dy Forward wy 4P | Spam [Ls Movey (= Print | More Actions ¥ 
E ; S/MIME (CAC) signed email Standard Header ¥ : 
& pred pertiad © Andrew Slack <aaslack@nps.edu> [“# Add Thursday, January 15, 2009 8:41:14 AM 
: To: Andrew Slack <aaslack@nps.edu>; Andrew Slack <andrewslackO2@yahoo.com>; andrewslackO2@gmail.com 

& inbox @ smime.p7s (5KB) 
‘E! Drafts = : ae 

= sent This is an S/MIME signed email, using my private key on my CAC. 

® spam Empty 

1 Trash Emotv 

Figure 27. Yahoo! Mail Signed Message View 
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B. DOMAINKEY AND DKIM 


Google’s Gmail signs each of its messages with a DKIM 
Signature to ensure that the message did indeed come from an 
“@gmail.com” address. Interestingly, Gmail also places a 
DomainkKey signature in the header as well. Since: boul. .of 
these methods only affect optional header fields, MUA’s that 
do not support DKIM or Domainkey simply ignore the 


Signature, and treat the message as unsigned. 


This is the full header that Google applies to the 
messages from Gmail. It includes both a DKIM and Domainkey 


Signature. 


From Andrew Slack Thu Jan 15 09:30:16 2009 

Return-Path: <andrewslack02@gmail.com> 

Authentication-Results: mtal90.mail.re2.yahoo.com from=gmail.com; domainkeys=pass (ok) 

Received: from 209.85.218.20 (EHLO mail-bw0-f20.google.com) (209.85.218.20) 

by mtal90.mail.re2.yahoo.com with SMTP; Thu, 15 Jan 2009 09:30:20 -—0800 

Received: by bwz13 with SMTP id 138s03348904bwz.17 
for <andrewslack0O2@yahoo.com>; Thu, 15 Jan 2009 09:30:16 -0800 (PST) 

DKIM-Signature: v=l1; a=rsa-sha256; c=relaxed/relaxed; 

d=gmail.com; s=gamma; 

h=domainkey-Signature: received: received:message-id:date:from:to 
subject :mime-version:content-type; 
=2QAR7pOiOFip6KP3V4yvG/ 6L2£fL8KfsYRIYcq61lyHzw=; 
=BUZ7kYDOYKBTDg/ttADhjHat+Zghl jieU/OFz43rlaJY21kUHJyLOoPdQ4kELe9rrDb 

NF1Gm/o0iAJsOPoLwU2 jyZSkT4yjadKhzhDo+th+YmdPMH0Za 9AJIBeAXR5u0ctZY52R4 
yfHYbxnhOwBygd1KNu7LsKRgbRQE7+ahcK0hg= 
Domainkey-Signature: a=rsa-shal; c=nofws; 
d=gmail.com; s=gamma; 
h=message-id:date:from:to:subject:mime-version:content-type; 
b=aN85NCqaLZ/6DO70DzSpNyZ jP4GVnatNPdmHss27uD7 rcENDESTN/nkRQALW8 9vVEUp 
FmQDBEVPCUavGoNS4psZyn/bFd5zuwWwGYMryw5 9Rzkq/cDtigWqdK+78qRxI2YNNynyFO 
EfuRZQOCQOT4iKssoe5KiFmByioDNH2ZGsrd+A= 
Received: by 10.223.114.68 with SMTP id d4mr1911859faq.86.1232040616283; 

Thu, 15 Jan 2009 09:30:16 —-0800 (PST) 
Received: by 10.223.110.202 with HTTP; Thu, 15 Jan 2009 09:30:16 —-0800 (PST) 
Message-ID: <3ad02d360901150930s3d5f3982ieb6e79ed90b436fef@mail.gmail.com> 
Date: Thu, 15 Jan 2009 09:30:16 -—0800 
From: "Andrew Slack" <andrewslack02@gmail.com> 
To: "Andrew (LT) Slack" <aaslack@nps.edu>, 

"Andrew Slack" <andrewslack0O2@yahoo.com>, 

"Andrew Slack" <andrewslack0O2@gmail.com> 
Subject: This is a DKIM (Gmail) signed email 
MIME-Version: 1.0 
Content-Type: multipart/alternative; 
boundary="——--—-=_Part_15066_23093755.1232040616277" 
Content-Length: 531 


































































































































































































1. Gmail 


Gmail does not show that a message contains a DKIM or 
Domainkey Signature, but if you expand the header, you can 


see the “signed-by” field. 


one 


DKIM Test t=" |x 


fy from Slacker02 <slacker0O2@gmail.com> nide details 5:54 PM (5 minutes ago) 7 Reply | ¥ 
to @4 andrewslackO2@gmail.com 
date Fri, Jan 30, 2009 at 5:54 PM 
subject DKIM Test 
mailed-by gmail.com 
signed-by gmail.com 





Figure 28. Google Mail DKIM/Domainkey Signature 


DomainKey Signed Message (Yahoo!) "ox |x | 


from Andrew Slack <andrewslackO2@yahoo.com> hide cetails 9:46 AM (2 minutes ago)  Reply| ¥ 
to aaslack@nps.edu, 
andrewslackO2@yahoo.com, 
@< andrewslackO2@gmail.com | 
date Thu, Jan 15, 2009 at 9:46 AM : 
subject DomainKey Signed Message (Yahoo!) 
mailed-by yahoo.com 
signed-by yahoo.com 


This message is digitally signed with DomainKeys by Yahoo!. 


© Reply “ Reply to all —> Forward 





Figure 29. Google Mail Domainkey Signature 


2. Yahoo! 


Yahoo! will show an icon within the message, indicating 


that it contains a DomainkKey signature. 





“this is a DKIM (Gmail) signed email Standard Header ¥ 
“<= 6&1 © Andrew Slack <andrewslack02@gmail.com> [ Add Thursday, January 15, 2009 9:30:16 AM 
To: Andrew (LT) Slack <aaslack@nps.edu>; Andrew Slack <andrewslackO2@yahoo.com>; Andrew Slack <andrewslack02@gmail.com> 





This is an email signed with Domain Keys Identified Mail (DKIM) from Google's mail server. 


Figure 30. Yahoo! Mail DomainKey Signed Icon 


Yahoo! ignores the DKIM signature, but verifies the 


DomainKkKey one. 


ol 


ce Outlook, Thunderbird, Apple Mail, Entourage, 
Webmail 


These MUA’sS do not support Domainkeys or DKIM at this 
time. Even though the header of the message contains the 
DKIM or DomainkKey signature, the MUA’sS treat the message as 
if there is no signature present. This 1s one of the 
advantages of incrementally deploying DKIM and similar 
domain-level authentication technologies: Mail services that 
do not have the DKIM software installed will not display an 
error, or an unknown attachment; it will just treat the 


message as unsigned. 


D2 


VII. CONCLUSION 


Phishing, and more importantly Spear Phishing, attacks 
against. DOD TnStitutvons. will Continue. to grow an: Meqnatude 
and SOphisSt ucat ton as adversaries increase their 
understanding of both the intended target and the potential 
advantages of compromised information. These attacks are 
intended to defeat normal spam firewalls, masquerade as 
legitimate email within an organization, and target the 


human as a weak point in network security. 


Official bulk email has the inherent attributes of 
authenticity and integrity, without the presence of a 
digital (signature. The combination of spear phishing 
attacks with official bulk email creates an extremely 
dangerous vector of attack into Department of Defense 
networks. Attackers, who have already defeated the 
automated network defenses, now have added trust to their 
fraudulent email stolen from the spoofed automated bulk 


email address. 


DiGrta. Signatures will he Lp mitigate this 
VUlIReTeaDidLiEyy, Jano Will oSeret- wn Ekrarning sancdividuals. ioe 
recognize fraudulent emails despite the sophistication of 
the attack. We have shown that it is relatively simple to 
employ an S/MIME proxy server, with test certificates, into 
an operational enclave email system to apply a digital 
Signature ie auto generated email. This Glave piers me 
authentication SOLUtLOn will only be possible Hie 
organizations can move past the administrative roadblocks 


such as legacy email architecture, the fear of altering a 


oe) 


working system, and obtaining role-based certificates 


despite enabling policy already in place. 


Department of Defense policy states the requirement for 
digital signatures on any email that meets certain criteria; 
Criteria that 16 almost <always Contained 2n. ofricial. bulk 
email. By not implementing a digital signature solution to 
automated official bulk email (whether it is an automated 
proxy server, or manual application), DoD enclaves are 


Vio Mea ean: “Oi tC aherd.. oO laey . 


The need for digital authentication on official bulk 
email is clear, the requirement for digital authentication 
on official bulk email 1s mandatory, and the automated 


solution is present. 


54 


LO | 


LIST OF REFERENCES 


E. Allman, “E-mail authentication: what, why, how?” 
ACM Queue. Vol. 4, No. 9 (November 2006), pp. 30-34, 
DOI= hEtpy//dol.acm,org/10,1145/71150175,11e0191, last 
accessed March 2009. 


P. Hallam-Baker, dotCrime Manifesto: How to Stop 
Internet Crime. Pearson Education, Inc. 2008. 


Department of Defense Instruction 8520.2, “Public Key 
Infrastructure (PKI) And Public Key (PK) Enabling.” 


Privacy Rights Clearinghouse Phishing Alert 
http://www.privacyrights.org/ar/phishing.htm, last 
accessed March 2009. 


J. W. Ragucci, S. A. Robila, "Societal Aspects of 
Phishing,” technology and Society, 2006. ISTAS 2006, 
TEER ANCE NaLTONal SYMPOSIUM On, Dp. J=-5, GS-10 wWune 
Z006;, URL: 

http://ieeexplore.ieee.org/stamp/stamp. jsp?arnumber=43 
75893&isnumber=4375875, last accessed March 2009 


Je Kiweky, “PayPal asks 25Ps vo Dlock unsigned email,” 
IDG News Service, Zi March. 2007. 


S. A. Robila and J. W. Ragucci, “Don't be a phish: 
steps in user education,” in Proceedings of the iith 
Annual SIGCSE Conference on innovation and Technology 
in Computer Science Education (Bologna, Italy, June 26 
+ AG, 2000), ATTCSHE “06, ACM, New York; NY, Dds237- 
ZA1,. DOL= hetet 77 do1.ac0,0ro/ 10,145 /1 1401 24.1140 ley, 
last accessed March 2009. 


A.J. Ferguson, “Fostering E-mail Security Awareness: 
The West Point Carronade,” Educause Quarterly. Vol. 
ZO; INO® de B2ZV0Ss De DA—57. 


Anti-Phishing Working Group, “Phishing Activities 
Trends Report O1/2008,™ 
http://www.antiphishing.org/reports/apwg_report_Q1_200 
8.pdf, last accessed March 2009. 

B. Brewin, “DoD Battles Spear Phishing,” Federal 
Computer Weekly, http://archive.cert.uni- 
stuttgart.de/isn/2006/12/msg00114.html, last accessed 
March “2009. 


eS) 


[11] 


[12] 


[17] 


[138] 


J. B. Postel, “RFC 821: Simple Mail Transfer 
Protocol,” Information Sciences Institute, University 
of Southern California. August 1982, 
http://www.ietf.org/rfc/rfc0821.txt, last accessed 
March 2009: 


J. Klensin, “RFC 2821: Simple Mail Transfer Protocol,” 
The Internet Society, 2001. 
http://www.ietf.org/rfc/rfc2821.txt, last accessed 
March 2009. 


Je Kbensan, “REC. 53212 Siamole Mail Transter Protocol.” 
Network Working Group. October 2008, http://www.rfc- 
edi torvorg/rirc/ricoszl.ter, last accessed March 2009. 


Alma Whitten and J. D. Tygar, "Why Johnny Can't 
Encrypt: A Usability Evaluation of PGP 5.0," in 
PrOCeECOINgGSs OF Che 60a USENIX Security Symposium, 
AUGUST 1999. 

http+/ /portal  eem.org/ citetion.ctim?id=1251435, last 
accessed March 2009. 


L. F. Cranor and S. L. Garfinkel, Security and 
Usability: Designing Secure Systems That People Can 
Use. O'Reilly Media Inc. 2005. p. 247. 


S. L. Garfinkel, D. Margrave, J. I. Schiller, E. 
Nordlander, and R. C. Miller, “How to make secure 
email easier to use” in Proceedings of the SIGCHI 
Conference on Human Factors in Computing Systems 
(POrcland, Oregon, USA, April O02 = OF, 2ZOUS)« Cal 705. 
ACM, New York, NY, pp. 701-710. 


S. L. Garfinkel and R. C. Miller, “Johnny 2: a user 
test of key continuity management with S/MIME and 
Outlook Express,” in Proceedings of the 2005 Symposium 
on Usable Privacy and Security (Pittsburgh, 
Pennsylvania, duly 06 — 08, 2005). SOUPS: "05, VOl« 93. 
ACM, New York, NY, pp. 13-24, DOI= 

hive? (oo... ecm. org/10.1145/71073001.1075003, last 
accessed March 2009. 


S. Gaw, E.W. Felten, and P. Fernandez-Kelly, “Secrecy, 
flagging, and paranoia: adoption criteria in encrypted 
email,” in Proceedings of the SIGCHI Conference on 
Human Factors in Computing Systems (Montréal, Québec, 
Canada, April 22 —= 27, 2006): « 


26 


[19] 


[22] 


bea 


G. D. Fritsche and S. K. Rodgers, “Encryption 
technologies: testing and identifying campus needs,” 
in Proceedings of the 35th Annual ACM SIGUCCS 
Conference on User Services (Orlando, Florida, USA, 
OGtoeber OF = LO, 2007). SIGUCCS: "07. ACM, New York, 
NY, pp.109-LizZ. DoOl= 
http://doi.acm.org/10.1145/1294046.1294071, last 
accessed March 2009. 


J. Linn, “RFC 1421: Privacy Enhancement for Internet 
Electronic Mail: Part I: Message Encryption and 
Authentication Procedures,” Network Working Group, 
February 1993, Hetot//ceols.16-1.corag/ ri e/r 61471 tet, 
last accessed March 2009. 


Philip R. Zimmermann, “Why I Wrote PGP”. Part of the 
Original 1991 PGP User's Guide (updated in 1999), 
http://www.philzimmermann.com/EN/essays/WhyIWrotePGP.h 
tml, Jast accessed. March 200%. 


J. Goodman, G. V. Cormack, and D. Heckerman, “Spam and 
the ongoing battle for the inbox,” Commun. ACM. Vol. 
50, No. 2 (February. 2007), pp. 24-33, DOI= 

http: //de7.acm.org/10.1145/ 121 16016,i1216017, last 
accessed March 2009. 

JTF-GNO Fact Sheet, 
http://www.stratcom.mil/factsheets/gno/, last accessed 
March 2000 

Department of Defense NAVADMIN 248/08 “Implementation 
of Navy Electronic Mail (Email) Digital Signature 
Policy.” 

Department of the Navy CIO Message DTG 2020412 AUG O/7, 
“Department of the Navy Security Guidance For Personal 
Electronic Devices (PED) .” 

Twisted Matrix Labs, 
http://twistedmatrix.com/trac/wiki/TwistedProject, 
last accessed March 2009. 


od 


THIS PAGE INTENTIONALLY LEFT BLANK 


Sie. 


APPENDIX 


A. PYTHON CODE —- SIGNING PROXY SERVER 


You can 


Se HEHEHE HE SHE HE 


A signing 


myname = 


myproxy = 
pemfile = 


from zope 


Original Copyright (c) 2001-2004 Twisted Matrix Laboratories. 
http://twistedmatrix.com/projects/mail/documentation/examples/ 
See LICENSE for details. 


run this module directly with: 


twistd -ny emailserver.tac 


email proxy. 


Wolognang Mari Proxy s70440.0 ce 
"Virginia.nps.edu" 
"BulkMail.pem" 


-interface import implements 


from twisted.internet import defer 
from twisted.mail import smtp 
import smime 


# http://python.net/crew/mwh/apidocs/twisted.mail.smtp.IMessageDelivery.html 
class ConsoleMessageDelivery: 
implements (smtp.IMessageDelivery) 


def __init (self): 
self.toaddrs = [] 


def receivedHeader(self, helo, origin, recipients): 
self.helo = helo 
return "Received: "+myname 


def validateTo(self, user): 


it 
it 


Right now, accept all messages. Eventually we want to only accept To addresses 
that the destination will accept. 


self.toaddrs.append (user) # make a copy 
return lambda: ConsoleMessage (self) 


def validateFrom(self, helo, origin): 


it 


All addresses are accepted 


self.fromaddr = origin 
return origin 


class ConsoleMessage: 
implements (smtp.IMessage) 


def _ init__(self,delivery): 
self.lines = [] 
self.delivery = delivery 


def lineReceived(self, line): 
self.lines.append (line) 


def connectionLost (self): 


it 


There was an error, throw away the stored lines 


self.lines = None 


def eomReceived(self): 


ow 


import email 
msg = "\r\n".join(self.lines) ) 
msg = smime.sign(msg, pemfile) 


# Send out the message using smtplib 

import smtplib 

server = smtplib.SMTP (myproxy) 

server.sendmail (self.delivery.fromaddr, self.delivery.toaddrs,msg) 
server.quit () 

return defer.succeed (None) 


class ConsoleSMTPFactory (smtp.SMTPFactory) : 


det... 3nit (S617 ,. Say. -*ekwys 
Smlp.SMTPPackory..-1nit.._ (self, *ay, **kw) 
self.delivery = ConsoleMessageDelivery () 


def ‘bul ldProtocel(self;, addr) : 
p = smtp.SMTPFactory.buildProtocol (self, addr) 
p.delivery = self.delivery 
FeLuUrh: © 


def main(): 
from twisted.application import internet 
from twisted.application import service 


a = service.Application("Console SMTP Server") 
internet .TCPServer (2500, ConsoleSMTPFactory()).setServiceParent (a) 


return a 


application = main() 


B. PYTHON CODE - OPENSSL 


#!/usr/bin/python 
tt 


# Sign a mail message using openssl 


def sign(msg,keyfile): 
mumsSign the RFC822 message using openssl. 
MSG should be a string. 
Returns a string. 


from subprocess import Popen, PIPE 


# Get the specific headers we care about to carry through 


msg822 = email.message_from_string (msg) 

headers = "" 

for field in ['To','From', 'Subject', 'Message-Id','x-mailer']: 
val = msg822.get (field) 
if val: headers = headers + field + ": " + val + "\r\n" 


# Sign the message 


proc = Popen(['openssl', 'smime', '-sign', '-signer',keyfile, '-inkey',keyfile], 
stdin=PIPE, stdout=PIPE, stderr=PIPE) 


(Signed_message, stderr) = proc.communicate (msg) 


# Add back those headers 
Signed_message = headers + signed_message 


Lt stderr: 
raise ValueError, stderr 
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if proc.returncode: 
raise ValueError,"OpenSSL returned Sd" % proc.returncode 
return signed_message 


if _ name__=="__main__": 

import sys,email 

msg = sys.stdin.read() 

Signed_message = sign(msg,sys.argv[1]) 

if len(sys.argv)>1: 
import smtplib 
server = smtplib.SMTP ("mxl.balanced.spunky.mail.dreamhost.com", 25) 
#server.set_debuglevel (1) 
server.sendmail ("BulkMail@nps.edu", ["test_recipient@nps.edu"],signed_message) 
server.quit () 
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